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REMARKS 

In the application, Claims 1, 16-21, 24-28, 35 and 37-41 are pending and rejected. The 
rejections raised in the Office Action of August 23, 2005 have been considered and comments 
are provided below. It is submitted that the claims as amended are in a condition for allowance 
and the Examiner is requested to reconsider the claims and issue a notice of allowance. 

Rejection under 35 U.S.C. §102 

The Examiner rejects Claims 1, 16-21, 24-28, 35 and 37-41 under 35 U.S.C. §102(b) as 
being clearly anticipated by Ermolaeva et al. 

The Examiner has maintained the prior rejection based on the assertion that the 
relational database of Ermolaeva et al. is the same as the multiple, separate databases claimed 
by Applicant. The Examiner cites the definition of "database" from Database Management 
Systems by Raghu Ramakrishnan (1 st Ed.) 1998, McGraw-Hill Companies, as a collection of 
data in support for his position that the tables within the relational database of Ermolaeva et al. 
(ArrayDB) are the same as multiple databases. While one must admit that a table within a 
relational database does include more than one item of data, this does not make multiple tables 
within a relational database equivalent to multiple, separate databases. In fact, in the same 
reference relied on by the Examiner, Ramakrishnan defines "relational database" as "a set of 
relations", where a relation is made up of 2 parts: "instance: a table, with rows and columns" 
and "schema: specifies name of a relation ..." (See attached Exhibit A, which are pages 
excerpted from the teaching slides prepared by the author for use with his textbook. The slides 
are available on the Internet at www.cs.wisc.edu.) A set of relations within a single database, 
as taught by Ermolaeva et al. is not the same as multiple, distinct databases within the database 
management systems of Applicant. 

Ermolaeva et al. describe their database as "an industry standard relational database 
management system combined with platform independent interfaces for data entry and 
retrieval", citing to P. Greenspun, Database Backed Web Sites: The Thinking Person s Guide to 
Web Publishing (Ziff-Davis, Emeryville, CA, 1997)." The full-text electronic edition of this 
book is available on the internet as "How to be a Web Whore Just Like Me" at 
http://philip.greenspun.com/wtr/dead-trees/. In Chapter 11, entitled "Choosing a Relational 
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Database", the author describes a relational database as "a big spreadsheet that several people 
can update simultaneously", where "each table in the database is one spreadsheet." (See 
Exhibit B.) Using this analogy, while a spreadsheet may be a collection of data, it would not be 
regarded by any person in the art as a database. Because Ermolaeva et al. teach only the use 
of a relational database, i.e., a collection of spreadsheets, they do not teach the use of multiple, 
distinct databases and, therefore, cannot anticipate Applicant's invention as claimed. 

To further emphasize the distinct nature of Applicant's databases, the base claims have 
been amended to include the limitation that communication between the databases, the user 
interface and the runtime engine occurs over a CORBA interface. CORBA (Common Object 
Request Broker Architecture) is a standard for interoperability in heterogeneous computing 
environments. (See Exhibit C, "CORBA Basics", from The C++ Report, October 29, 1997, 
available on the Internet at http://ootips.org/corba-basics.html.) This additional limitation 
supports Applicant's, position that the databases are distinct, i.e., heterogeneous, and that an 
interface is used to allow communication between the databases. This limitation is supported 
in the specification at page 81, last paragraph, and in Figure 7, where the CORBA interface 
between the databases, runtime engine and user interface is clearly illustrated. It is submitted 
that Ermolaeva et al. do not disclose a CORBA interface and, therefore, cannot anticipate 
Applicant's invention as now claimed. 

The present application claims a database management system and method for gene 
expression data, not merely a relational database containing gene expression data. For the 
foregoing reasons, the Ermolaeva et al. reference does not teach each and every element and, 
therefore, cannot anticipate Applicant's invention as now claimed. Accordingly, Applicant 
respectfully requests that the Examiner withdraw the rejection under §102(b). 

In view of the foregoing amendments and remarks, Applicant submit that all bases for 
rejection have been addressed and overcome such that the amended claims are allowable over 
the prior art. Accordingly, Applicant respectfully requests that the Examiner withdraw all 
rejections set forth in the Office Action and issue a notice of allowance for all claims now in 
the application. 



40I0-US - Amendment in Response to 8/23/05 OA.2005.K23 
111944.000015/570997.01 



11 



Serial No. 09/862,424 
Response to Office Action of August 23, 2005 



Should the Examiner believe that prosecution of this application might be expedited by 
further discussion of the issues, he is invited to telephone the undersigned attorney for 
Applicant at the telephone number indicated below. 



Procopio, Cory, Hargreaves & Savitch LLP 
530 B Street 
Suite 2100 

San Diego, California 92101 
Telephone: (760) 931-9700 
Facsimile: (760) 931-1155 
E-mail: emm@procopio.com 



Docket No. 401 OUS (1 1 19440-000015) 



Respectfully submitted, 



Dated: November 23, 2005 




Eleanor M. Musick J 
Attorney for Applicant 
Registration No. 35,623 
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